[% setvar title The Perl 6 Summary for the week ending 2005-10-30 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 2005-10-30'></a><h1>The Perl 6 Summary for the week ending 2005-10-30</h1>
<p>Hmm... Thursday afternoon and I've only just started writing the
summary... What happened to professionalism? What happened to rigid, albeit
self-imposed deadlines?</p>
<p>Um... I've had a cold. The cats ate my homework.</p>
<a name='This week in perl6-compiler'></a><h1>This week in perl6-compiler</h1>
<p>It's weird isn't it? Activity on Pugs and the other Perl 6 compiler tools shows
no signs of slowing (especially now conference season is over), but the
volume of mail on the list continues to be tiny. Autrijus seems to be Erdösing
round Europe and writing everything up on use.perl. I could give you a bunch of
links to various other blogs and journals where various Perl 6 developers are
writing up their work, but it's probably easiest just to point at the Planet
Perl Six aggregator. It's good to see so much of this stuff becoming a little
more visible.</p>
<p><a href='http://planetsix.perl.org/' target='_blank'>planetsix.perl.org</a></p>
<a name='Meanwhile, in perl6-internals'></a><h2>Meanwhile, in perl6-internals</h2>
<p>Discussion of the Parrot JSON serialization code span off into a discussion of
generalized serialization for Parrot data structures.</p>
<p><a href='http://groups.google.com/groups?threadm=7db97f67dbbb75925a049e678711aa62@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Determining the number of return values expected'></a><h2>Determining the number of return values expected</h2>
<p>Leo and Jonathan Worthington discussed how to find out about the number and
types of return values the caller expects. Jonathan ended up implementing an
experimental op to kick around.</p>
<p><a href='http://groups.google.com/groups?threadm=40b8683112eda4dd7baaf23336d60482@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Rules for changing APIs'></a><h2>Rules for changing APIs</h2>
<p>Leo talked about the Parrot policy for changing APIs. In general, it's a good
idea not to have to change a public API, but in practice, it happens. As Leo
said, the general rule is &quot;You break it, you fix it&quot;, so the policy is that if
any API changes break anything in the Parrot subversion tree, it's up to
whoever changed the API either to fix it or to work with the the sub project's
'owner' to get it fixed. Projects that aren't in the tree will need to keep
themselves up to date, but if you didn't document your changes well enough,
expect to be fielding questions for a while after your changes.</p>
<p><a href='http://groups.google.com/groups?threadm=20051024190140.GC12998@tytlal.topaz.cx' target='_blank'>groups.google.com</a></p>
<a name='check_progs is not portable'></a><h2><code>check_progs</code> is not portable</h2>
<p>François Perrad pointed out that the <code>check_progs</code> subroutine used by Parrot's
config system doesn't work on windows. He suggested using the CPAN module
File::Which instead. This turned into a discussion about whether it would be
good to have a Bundle::Parrot set up on CPAN with all the CPAN modules needed
for Parrot to build, or if we should continue to bring those modules that
Parrot needs into the Parrot distribution so that, once you've downloaded the
Parrot tar file you won't need to scurry off to CPAN for various supporting
bits and pieces.</p>
<p><a href='http://groups.google.com/groups?threadm=5.1.0.14.2.20051024222708.01cd0c80@pop.besancon.parkeon.com' target='_blank'>groups.google.com</a></p>
<a name='The Configure System'></a><h2>The Configure System</h2>
<p>Understating the case somewhat, chromatic pointed out that the plugin system for
configuration is grotty. Everyone agreed pretty much, but the question is
whether to do anything about it since the current configuration is supposed to
be a stopgap solution until we get the proposed miniparrot scheme up and
running. Pretty big gap eh?</p>
<p>Hopefully this means we're going to get work started on the miniparrot
approach. Or maybe someone will clean up the stopgap. Neither would be bad.</p>
<p><a href='http://groups.google.com/groups?threadm=1130269365.32760.22.camel@localhost' target='_blank'>groups.google.com</a></p>
<a name='Yet another C compiler'></a><h2>Yet another C compiler</h2>
<p>Leo pointed everyone at the Amsterdam Compiler Kit, which is the default
compiler for Minix and wondered if anyone wanted to experiment with it to see
if it could compile parrot.</p>
<p><a href='http://tack.sourceforge.net/' target='_blank'>tack.sourceforge.net</a></p>
<p><a href='http://groups.google.com/groups?threadm=435E0499.6050106@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Deprecation warning'></a><h2>Deprecation warning</h2>
<p>Leo announced that the <code>newsub</code> operator is about to be removed. Check
<b><i>docs/compiler_faq.pod</i></b> for details of the Right Way of making subs. Patrick
had a few questions so he could track the changes in PGE. Leo answered them.</p>
<p><a href='http://groups.google.com/groups?threadm=435E1CD0.10306@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Compiling parrot with c++'></a><h2>Compiling parrot with c++</h2>
<p>Nick Glencross wondered if it would be a good idea to make it so that Parrot
couple be compiled by a compiler in C++ mode. The answer appeared to be
'yes'.</p>
<p><a href='http://groups.google.com/groups?threadm=20051026105158.12050.qmail@lists.develooper.com' target='_blank'>groups.google.com</a></p>
<a name='Documenting new_pad'></a><h2>Documenting <code>new_pad</code></h2>
<p>Jerry Gay asked about the use of the <code>new_pad</code> op, which appears to be both
undocumented and untested. Not good. He posted some apparently reasonable code
that fails. Matt Diephouse reduced it to a simpler failing case and Leo tracked
down the bug. None of which addresses the lack of documentation of course, but
it's a start.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-3.0.11-37540-123336.3.23120442924065@perl.org' target='_blank'>groups.google.com</a></p>
<a name='&quot;All tests successful&quot; considered harmful'></a><h2>&quot;All tests successful&quot; considered harmful</h2>
<p>Jerry Gay pointed out that &quot;All tests successful&quot; is only a useful message when
you're confident that your test suite has good enough coverage. Jerry thinks
parrot has too few tests. So he's started writing more and sending in
patches. He noted that trying to write tests was a very good way of discovering
areas of Parrot that aren't sufficiently (at all) specced. He called for others
to join him in writing tests and picking off parrot's low hanging fruit. Go
Jerry!</p>
<p>One of Jerry's issues was that you can't easily write tests in PIR. So
chromatic pointed him at his Test::Builder ported to PIR and committed to
getting Parrot::Test (or some useful subset of it) ported to make use of it. Go
chromatic!</p>
<p><a href='http://groups.google.com/groups?threadm=1d9a3f400510271026i60c55711s15ae0f3c61dd8a26@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Rejigging NCI to use the ffcall library'></a><h2>Rejigging NCI to use the ffcall library</h2>
<p>Nick Glencross wondered about rejigging NCI, the parrot Native Call Interface
to use the ffcall library. In fact he went so far as to offer up a proof of
concept implementation. Apparently the ffcall approach makes it much easier to
write callbacks in PIR/PASM. Leo thought it sounded like a useful thing to do,
but licensing issues (ffcall is under the GPL) meant that Parrot might have to
stick with the current NCI interface.</p>
<p><a href='http://groups.google.com/groups?threadm=436288A0.8020105@glencros.demon.co.uk' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='That darned class sigil'></a><h2>That darned class sigil</h2>
<p>I just can't keep track... When Larry originally introduced a class sigil, it
was <code>¢</code>. The discussion went off in several directions and, as I write this
and the next summary will probably say that the sigil is now longer ¢ because
of difficulties typing the character on Asian keyboards. The discussion was
generally in favour of some kind of new sigil though.</p>
<p><a href='http://groups.google.com/groups?threadm=20051020145609.GA3551@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Perl 6 Fears'></a><h2>Perl 6 Fears</h2>
<p>Juerd announced that he's added a list of Perl 6 fears to the pugs
distribution. The idea is to gather all the things that worry people about Perl
6 into one place and see what, if anything can be done to address them. People
don't seem to like Unicode operators...</p>
<p>Slightly tangentially to this, Dan Sugalski blogged a couple of weeks ago about
his successes and failures with Parrot. The comments are worth reading --
there's a fair few more or less well founded complaints about the way the Perl 6
project has been managed, many of which seem already to have been
addressed. Certainly the design process is rather more visible now.</p>
<p><a href='http://groups.google.com/groups?threadm=20051023222021.GG24163@c4.convolution.nl' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.sidhe.org/~dan/blog/archives/000435.html' target='_blank'>www.sidhe.org</a></p>
<a name='Ways to add behaviour'></a><h2>Ways to add behaviour</h2>
<p>Ashley Winters has been thinking about all the different ways to add behaviour
to classes in Perl 6. He came up with 7 and I think he missed a few...</p>
<p>A discussion between span off with Larry and Stevan talking about the hows of
whys of adding behaviour via <code>.meta</code>, which in turn morphed into a wider
discussion of how the Perl 6 metamodel's going to work. I find myself wondering
what we're going to run out of first, Unicode characters for new operators, or
terms for MetaModel concepts.</p>
<a name='$_ defaulting for mutating ops'></a><h2><code>$_</code> defaulting for mutating ops</h2>
<p>Quickly, what does a line of code like:</p>
<pre>  given $subject { ++ }</pre>
<p>do? Juerd thinks it should increment <code>$_</code>/<code>$subject</code>. The idea being that all
mutating operators should default to operating on <code>$_</code> in the absence of any
other operand. Larry pointed out that, as you can already use <code>.</code> on any
postfix operator, it's already possible to write</p>
<pre>  given $subject { .++ }</pre>
<p>He reckoned that changing the other operators in the way Juerd proposed would
probably be a losing proposition. I'm not sure Juerd was convinced.</p>
<p><a href='http://groups.google.com/groups?threadm=20051025074428.GR24163@c4.convolution.nl' target='_blank'>groups.google.com</a></p>
<a name='txt vs OO'></a><h2>txt vs OO</h2>
<p>Michele Dondi replied to Stevan's assertion of a few weeks ago that &quot;Perl 6's
OO system has the potential to be to OO programming what Perl 5 etc, was to
text processing&quot;. Michele thought that being known for OO might well be as much
of a trap as being known for text processing was for Perl 5 (at least to the
wider community of programmers who didn't look further than the headlines). In
the ensuing discussion, Larry came up with the idea that the design of Perl 6
is aimed at making it possible to 'usefully cargo cult aspects of interest'
without having to learn the whole damned language. When the OED adds the verb
form of 'cargo cult' to its corpus, remember where you read that first. Even if
you're not that interested in the rest of the thread, it's worth reading what
Larry has to say on this.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.62.0510171136490.19555@worf.pcteor1.mi.infn.it' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20051026123802.GA21529@wall.org' target='_blank'>groups.google.com</a> -- Larry on cargo culting</p>
<a name='+$arg changed to :$arg'></a><h2><code>+$arg</code> changed to <code>:$arg</code></h2>
<p>Larry announced that one of the major changes in the latest version of Synopsis
6 was that named arguments are now marked with <code>:</code> and not <code>+</code>. The aspect of
this that had me punching the air and shouting &quot;Yes!&quot; was that it's now
possible to declare a parameter with both an external name and an internal
variable name (which is one of the aspects of Smalltalk style method selectors
that I really like). After a long post of thinking aloud, he went off to revise
the synopsis again. Discussion of the implications of using <code>:</code> ensued.</p>
<p><a href='http://groups.google.com/groups?threadm=20051026134439.GA22830@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Roles vs. Classes'></a><h2>Roles vs. Classes</h2>
<p>Rob Kinyon wondered if the only difference between a Role and a Class was that
the Role was immutable. He reckoned that, if that was the case he'd rather use
Roles all the time. Luke, chromatic and Larry thought he was wrong about this,
pointing out that open/closed optimizations should be left to the class's
clients not to the class itself. Essentially, if everything declares that it's
not going to monkey with everything else after the compile phase is over, then
perl can get on and optimize like an optimizing monkey based on the (good)
assumption that all classes are closed for the duration of the program's
execution.</p>
<p><a href='http://groups.google.com/groups?threadm=70384420510261729x3122a1banbf07100bfeb1e4ce@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Is there a way to generate an object without a new?'></a><h2>Is there a way to generate an object without a new?</h2>
<p>Yiyi Hu doesn't want to have to type 'new', preferring instead to do
<code>Class( b =&gt; 5)</code>. Luke liked the idea. Juerd didn't. Larry pointed that
making it work would have unpleasant syntactic ramifications.</p>
<p><a href='http://groups.google.com/groups?threadm=f469f8de0510271217v2e20f469kadff7b6987140b04@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Role Method Conflicts and Disambiguation'></a><h2>Role Method Conflicts and Disambiguation</h2>
<p>Stevan had some questions about how method conflict resolution works with
roles. He had a few simple, if pathological cases to demonstrate the
issues. Various solutions were proposed, but I did find myself thinking of the
old joke: &quot;Doctor, it hurts when I do this.&quot;</p>
<p>&quot;Well, don't do that then.&quot;</p>
<p>Ahem. The old ones are still the old ones. And the Old Ones are still the Old
Ones, but I don't think we've yet added &quot;Perl Six will awaken great Cthulhu
from his long sleep beneath the island of R'Lyeh&quot; to the Perl Six fears list.</p>
<p><a href='http://groups.google.com/groups?threadm=13B51746-7A57-4482-A637-7202B99F2006@iinteractive.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=7ca3f0160510281844v708c419ekea6c0769a78c1841@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Crossing lists'></a><h2>Crossing lists</h2>
<p>Darren Duncan wants a 'simple way to combine 2 arrays where every element of
each array is combined with every element of the other arrays', he calls this
the <code>cross</code> operator. Luke pointed to several places where it, or something
like it had already been discussed, but I don't think it's something that's
made it in to the language.</p>
<p><a href='http://groups.google.com/groups?threadm=p06230900bf8764a38dd2@' target='_blank'>groups.google.com</a>[192.168.1.101]</p>
<a name='Acknowledgements, apologies and everything else'></a><h1>Acknowledgements, apologies and everything else</h1>
<p>Sorry it's late. I'll do better next time.</p>
<p>I'm still looking for work; perl or ruby programmer, photographer, tech writer,
folk singer -- I'm multi talented. Let me know if you need any of 'em. Also, if
anyone is interested in taking up sponsorship of the Summaries, please drop me a
line, I'd be delighted to hear from you.</p>
<a name='Help Chip'></a><h2>Help Chip</h2>
<p><a href='http://geeksunite.org/' target='_blank'>geeksunite.org</a> -- Chip still needs help.</p>
<a name='The usual coda'></a><h2>The usual coda</h2>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p>Check out my website, it's lovely.</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a></p>
<p>Vaguely pretty photos by me can be found at:</p>
<p><a href='http://www.flickr.com/photos/pdcawley' target='_blank'>www.flickr.com</a></p>
</div>
